home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7469 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.2 KB
  1. Path: news.mindlink.net!news
  2. From: genew@mindlink.bc.ca (Gene Wirchenko)
  3. Newsgroups: comp.lang.pl1,comp.lang.c
  4. Subject: Re: PL/I and C
  5. Date: Mon, 26 Feb 1996 20:37:36 GMT
  6. Organization: MIND LINK! - British Columbia, Canada
  7. Message-ID: <4gt5sm$jra@fountain.mindlink.net>
  8. References: <4gh5ru$eng@goanna.cs.rmit.EDU.AU> <4gn5d8$t5f@newsbf02.news.aol.com> <4gril3$sn9@goanna.cs.rmit.EDU.AU> <31320777.2810@corp.dialog.com>
  9. NNTP-Posting-Host: line254.nwm.mindlink.net
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. Paul Gorodyansky <paul_gorodyansky@corp.dialog.com> wrote:
  13.  
  14. >As I said, I just found out that my posting went also to
  15. > comp.lang.C group, in addition to PL/I group.
  16.  
  17. [snip]
  18.  
  19. >   All you, C guys who replied, paid TOO MUCH attention to my note
  20. >about UNIONS, but it's a MINOR thing compared to other AWFUL for
  21. >an *application* programmer  things in C that I listed.
  22. >In systems/low-level tasks C may be Perfect.
  23.  
  24. >After so many replies that did not quote these MAJOR things, I am
  25. >posting to comp.lang.C group LAST time, repeating the items, that,
  26. >in my opinion, make C a *bad* choice for
  27. >  an *application* Production environment,
  28.  
  29.      C is used for apps.
  30.  
  31. >  where Fix time is *critical*,
  32.  
  33.      Considering some of the interactions I ran into in using PL/I,
  34. this is not a point in its favor.
  35.  
  36. >  where are MANY (not ONE package for market) *different* programs,
  37.  
  38.      How is this point relevant?
  39.  
  40. >  OFTEN to be changed due to Specs changes,
  41.  
  42.      How is this point relevant?
  43.  
  44. >  often by several engineers, who may see *this* program and
  45. >  *this* data(Huge) FIRST time and have COUPLE hours to fix it.
  46.  
  47.      Programmers program.  Engineers engineer.
  48.  
  49.      A bit of a troll?
  50.  
  51. >   It is known that C is lower  level language that PL/I, 
  52. >it's closer to Assembly. Nothing wrong with it, moreover, 
  53. >it's why C programs usually are much more efficient.
  54.  
  55. >   BUT 'there is no free lunch' and this effectiveness causes
  56. >LESS readability.  
  57. >PL/I is reacher, so it's is easier to implement things there and
  58.          ???????
  59. >make a code more readable.
  60.  
  61.      Richer perhaps?
  62.      No, C just doesn't have a complex syntax.  Many things are
  63. implemented as functions.  For example, why learn a separate syntax
  64. for I/O.  All C I/O is through functions.
  65.  
  66. >Just 2 examples of our NORMAL, REGULAR code (nothing special).
  67.  
  68. >I. Select/Switch statement. 
  69. >----------------------- 
  70. >  This important part of ANY *application* program is VERY
  71. >        ------- 
  72. >   rudimental and hard to use in C - you can use ONLY numbers here:
  73.  
  74.      Agreed.  I've already offered to sell my rights in the use of
  75. switch.  No takers so far.  <G>
  76.  
  77. [snip]
  78.  
  79. >Just another example. Strings.
  80.  
  81. >   C has this VERY STUPID limitation - a 'string' in C it's a set of
  82. >bytes with x'00' at the end ! 
  83. >But, we have x'00' all over our source data !
  84. >For example, we have on-line European Patent Office data (only ONE of
  85. >our 400+ *different* applications), and source file is 40 gigabytes (!)
  86. >FULL of x'00' !!!
  87.  
  88.      Not true.  It's just that is the way string.h is defined.  You
  89. are free to set up strings as you wish.
  90.  
  91. >    Also, C does not have Variable Length Strings, that are VERY
  92. >important for our *application* programs. Again, this feature helps to
  93. >have programs SHORTER, more READABLE, and CLOSER to specs.
  94.  
  95.      C DOES have variable length strings.  Take a look at strlen().
  96.  
  97. >    And now imagine how IT (foo-o-o) looks in OUR programs, where
  98. >due to this STUPID x'00' limitation, we even can not use THESE
  99. >(not very friendly) functions, and MUST use operations on
  100. >BUFFERS, i.e. mem.. functions, taking through a code Length of
  101. >buffers all the time ! 
  102. >   Same Program in PL/I is 100 times more readable and is 100 times
  103. >more easy to CHANGE and FIX.
  104.  
  105.      If you do not have the proper functions, yes, you can have
  106. trouble.  What do you do in PL/I if the standard staatements and
  107. operators don't meet your needs?  In C, you write a library.
  108.  
  109. >So, my points are the following.
  110. >  Open Systems people very often tell that *only* C
  111. >should be used EVERYWHERE, and it's wrong - you never go to
  112. >a farmer's field with a handbag, and to a food store with a truck -
  113. >tasks are different, and some can be done better with C,
  114. >and some - with PL/I.
  115.  
  116.      This is news?  When did you catch on?
  117.  
  118. >   For *application* programming *Production* environment with a lot 
  119. >of Text Processing, and a lot of *different* and often *changed* 
  120. >   ---------------                               -----
  121. >programs, PL/I is MUCH, MUCH better than C:             
  122. > - PL/I has wider set of statements, so it is much easier in PL/I
  123. >   to make a code be CLOSE to specs, so next person will understand
  124. >   a code faster and can FIX program faster;
  125.  
  126.      Therefore, you have to know more to program in it.  The
  127. statements also interact to an alarming degree.  I don't use PL/I
  128. anymore and I'm glad of it.  PL/I = "Pretty Lousy One" in my lexicon.
  129. YMMV.
  130.  
  131. > - if a language REQUIRES workaround OFTEN, then it is LESS readable 
  132. >   than another language that is reacher.
  133.  
  134.      I had to workaround PL/I signals, so I know what you mean.  PL/I
  135. makes for bletcherous code if you try to handle all cases.
  136.  
  137. [snip]
  138.  
  139. Sincerely,
  140.  
  141. Gene Wirchenko
  142.  
  143. C Pronunciation Guide:
  144.      y=x++;     "wye equals ex plus plus semicolon"
  145.      x=x++;     "ex equals ex doublecross semicolon"
  146.  
  147.